Concurrent Object-Oriented Programming: The MP-Eiffel Approach

concurrent programming Since we are interested in the essential properties of concurrency, we don’t want to bind our concurrent processing entities to specific “lower level” realizations such as threads, processes, object request brokers, MPI, PVM, or any other. Instead, we will use an abstract notion of “processor” adapted from Meyer [Mey97, page 964]: A processor is an autonomous thread of control capable of supporting the sequential execution of instructions. 98 JOURNAL OF OBJECT TECHNOLOGY VOL 3, NO. 4 2 CONCURRENT PROGRAMMING Nothing is assumed on how this virtual processor will be implemented at runtime. We won’t even exclude the possibility that a processor may start by being a thread in one machine and end as a process in another through a remote procedure call mechanism. In general, concurrency does not require simultaneous (parallel) processor execution. A concurrent program can be thought as the concurrent execution of sequential “programs”, one for each processor (of course, they may depend highly on each other). From a concurrent programming system we expect the ability to – safely – specify and control two things: • concurrent execution of processors; • inter-processor synchronization and communication. Concurrent execution of processors Concurrent systems need mechanisms to start, support, and terminate the execution of processors, either as part of the programming language constructs or provided in a library. In particular they need to assign processors to specific processing devices (threads, processes, computers in a distributed system, or any other). This assignment will be called heterogeneous if the concurrent system allows the assignment of different processing devices for processors, otherwise it will be classified as homogeneous processor mapping. Heterogeneous processor mapping is a desirable property since it enforces the decoupling between a concurrent program and specific processing devices. However, specific types of concurrent programming, such as real-time and embedded systems may pose strong restrictions to valid (feasible) processor mappings. Inter-processor synchronization and communication To ensure a correct inter-processor interaction it is necessary to enforce proper timing constraints between them. Such synchronization requirements may arise from the necessity to guarantee safety properties [Lam83], the verification of some condition, the need to impose a specific processor scheduling strategy [RF77], or several of these possibilities at the same time.